This file appears to have been reformatted with spacing changes (spaces after colons added throughout) but no functional changes. This seems unintentional as it's not mentioned in the PR description and is unrelated to the inspector panel feature. Consider reverting these formatting changes to avoid unnecessary noise in the diff.

There's duplicate logic for loading table metadata: once in the .task modifier when the tab changes (lines 104-113) and once in the onReceive handler when the inspector is toggled (lines 378-383). Both check the same conditions (whether the table name matches the current metadata). This could lead to unnecessary duplicate API calls if both conditions trigger simultaneously. Consider consolidating this logic into a single function or removing one of these redundant checks.

Error handling only logs to console with print, which makes it difficult for users to know why table metadata failed to load. The inspector panel will silently show no metadata on error. Consider displaying an error state in the UI (e.g., an error message in the inspector panel) or using proper logging infrastructure to make debugging easier.

The search field and clear button lack accessibility labels, which could make the inspector panel harder to use with VoiceOver or other assistive technologies. Consider adding .accessibilityLabel() modifiers to the search field and clear button to describe their purpose.

The type is hard-coded as "string" for all columns regardless of the actual column data type. This provides limited value to users inspecting row details. Consider retrieving actual column type information from the result metadata or the schema. The comment acknowledges this can be "enhanced later", but displaying incorrect type information could mislead users.

The query hardcodes the schema name as 'public', which may not work correctly for tables in other schemas. Users working with tables in custom schemas (e.g., 'myapp', 'staging') will not be able to view metadata for those tables. Consider either accepting the schema name as a parameter, using the search_path to determine the appropriate schema, or querying across all accessible schemas.

The comment states "SHOW TABLE STATUS LIKE expects a pattern string literal" but the query actually uses "WHERE Name =" which is an equality comparison, not a LIKE pattern match. The comment should be updated to reflect that this is a WHERE clause with string comparison, not a LIKE pattern. The escaping is correct for preventing SQL injection in string literals.

The fetchTableMetadata implementation builds a MySQL query by interpolating tableName into a single-quoted string and only escapes single quotes, which is not sufficient to prevent SQL injection in MySQL/MariaDB string literals. Because backslash escapes are enabled by default, a crafted table name or value such as abc\'; DROP TABLE important;-- can use \' to terminate the string despite the single-quote doubling and inject additional statements, executed with the full privileges of this connection. To fix this, avoid manual string concatenation here by using parameterized queries or the driver’s native literal-escaping API, or at minimum also correctly escape backslashes and other special characters when embedding identifiers as string literals.